Modern computer architectures often include processor specific instructions as part of a startup sequence. These processor specific instructions are often employed for boot-up and/or recovery operations and may be stored in a storage device (e.g., flash storage devices, etc.).
Having the capability to update the boot-up and/or recovery sequence, components, code, binaries, and/or data permits greater flexibility in reusing these binaries in different platforms, correcting errors or bugs to existing components or binaries, and/or adding new features to existing boot-up and/or recovery sequences. The boot-up or recovery firmware is often stored as an image in a storage device (e.g., read-only memory, flash storage, etc.) from where it is accessed for processing.
For example, the current Itanium™ architecture from Intel Corp. partitions its boot-up and recovery firmware (i.e., binaries, data, code, etc.) into several distinct logical components, layers, or services. For instance, the “Processor Abstraction Layer” (PAL) components provide services directly related to the processor and insulates the remainder of the firmware from any processor-specific requirements. The “System Abstraction Layer” (SAL) provides the services necessary to configure the particular chipset and all other platform-specific functions. Layers may be divided into type “A” and type “B” components. In general, type “A” components (e.g., PALA and SALA) typically provide a minimum set of operations required for a recovery operation and type “B” components (e.g., PALB and SALB) typically extend the type “A” component operations to provide full boot-up support.
Typically, PAL components are specific to each processor. Thus, each processor type may require a different PALA/PALB combination.
An Itanium™ processor will not function without the PAL firmware. Additionally, the PAL actually contains the reset vector (as well as other hardware vectors) which is employed for boot-up and/or recovery. For these reasons, the PAL is located at a fixed address. FIG. 1 is a block diagram illustrating a prior art implementation of a boot-up or restart sequence. A computer, system, or processor is typically configured to start by accessing a fixed vector (e.g., reset vector) location 102 which points to the starting address for the boot-up or restart procedure. In the PAL/SAL architecture illustrated, a single, fixed pointer (106) into the SAL component is provided to the PAL providing a discoverable entry point for SAL services. The PAL is executed as a result of the processor reset. Once the PALA has examined and validated critical processor related resources (including PALB), control will be passed to the SALA (at pointer 106.) The SALA (108) then performs its own set of system resource and system firmware validation. Invocation of subsequent components or services (110) is performed as necessary to boot or recover the system.
As features are added or bugs are discovered in the boot-up and/or recovery procedures, it is often desirable to upgrade the PAL and/or SAL components to include these new features, services, and/or fixes. This may be accomplished by re-flashing the memory or storage location(s) or blocks where the PAL and/or SAL components are stored. That is, the affected PAL and/or SAL components in the firmware are updated and/or replaced with different components.
However, a side effect of having a single fixed address or location for the reset vector (e.g., 102) and SAL entry point (e.g., 106) is that any unexpected event or interruption (e.g., a power failure, etc.) in the update of the PAL and/or SAL has the potential to render the system useless. The interruption can be any event that occurs during a firmware update that does not allow the update to fully complete thus having the potential to render the system fully or partially useless or corrupt. For example, if an interruption occurs during the re-flashing process, the reset vector or other fixed address PAL and/or SAL components may become corrupt and make the processor inoperable.
Some platform-based solutions exist that allow fault resilient PAL updates but require significant additional Bill of Materials (BOM) cost to support redundant flash components or require significant chipset modifications to provide addresses aliasing.
It can also be seen that if the PAL is processor-specific and must be located at a fixed address, a given firmware image may only support a single processor type at a time. Switching between processor types would require updating (e.g., re-flashing) the fixed PAL area with a PAL that supports the new processor. This updating of fixed-location PAL components has the potential to result in significant downtime, a catastrophic failure, or corruption if the PAL firmware update is interrupted, halted due to an unexpected event, or if the wrong PAL firmware is used during the update.